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NASA is planning a series of short and long duration human and robotic missions to 
explore the Moon and then Mars. The series of missions will begin with a new crew 
exploration vehicle (called Orion) that will initially provide crew exchange and cargo supply 
support to the International Space Station (ISS) and then become a human conveyance for 
travel to the Moon. The Orion vehicle will be mounted atop the Ares I launch vehicle for a 
series of pre-launch tests and then launched and inserted into low Earth orbit (LEO) for 
crew exchange missions to the ISS. The Orion and Ares I comprise the initial vehicles in the 
Constellation system of systems that later includes Ares V, Earth departure stage, lunar 
lander, and other lunar surface systems for the lunar exploration missions. These key 
systems will enable the lunar surface exploration missions to be initiated in 2018. The 
complexity of the Constellation system of systems and missions will require a communication 
and navigation infrastructure to provide low and high rate forward and return 
communication services, tracking services, and ground network services. The infrastructure 
must provide robust, reliable, safe, sustainable, and autonomous operations at minimum cost 
while maximizing the exploration capabilities and science return. The infrastructure will be 
based on a network of networks architecture that will integrate NASA legacy 
communication, modified elements, and navigation systems. New networks will be added to 
extend communication, navigation, and timing services for the Moon missions. Internet 
protocol (IP) and network management systems within the networks will enable 
interoperability throughout the Constellation system of systems. An integrated network 
architecture has developed based on the emerging Constellation requirements for Orion 
missions. The architecture, as presented in this paper, addresses the early Orion missions to 
the ISS with communication, navigation, and network services over five phases of a mission: 
pre-launch, launch from TO to T+6.5 min, launch from T+6.5 min to 12 min, in LEO for 
rendezvous and docking with ISS, and return to Earth. The network of networks that 
supports the mission during each of these phases and the concepts of operations during those 
phases are developed as a high level operational concepts graphic called OV-1, an 
architecture diagram type described in the Department of Defense Architecture Framework 
(DoDAF). Additional operational views on organizational relationships (OV-4), operational 
activities (OV-5), and operational node connectivity (OV-2) are also discussed. The system 
interfaces view (SV-1) that provides the communication and navigation services to Orion is 
also included and described. The challenges of architecting integrated network architecture 
for the NASA Orion missions are highlighted. 
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I. Introduction 

A main objective of NASA’s Vision for Space Exploration (VSE) 1 is extending human presence across the solar 
system starting with the return of humans to the Moon by the year 2020, in preparation for human exploration of 
Mars and other destinations. In response to the VSE, NASA established the Exploration Systems Mission 
Directorate (ESMD) within which the manned Constellation Program (CxP) was established. The Space 
Communication and Navigation (SCaN) Program Office was created within the Space Operations Mission 
Directorate (SOMD) to implement needed end-to-end communication and tracking infrastructure for the ESMD 
missions. 

A series of test and support flights involving transportation of cargo and crew in the Orion crew exploration 
vehicle (CEV) to the International Space Station (ISS) will “spear-head” the mission set. Missions transporting crew 
and cargo to the Moon will follow this. Eventually transportation to Mars and beyond is envisaged. 

The communication and navigation architecture described in this paper is for the initial Orion to ISS Mission 2 . 
The primary purpose is to describe the architecture in a manner that establishes interoperability between systems 
owned and operated by separate organizations within and external to NASA. 

NASA’s near term exploration plans 2 call for human and robotic missions to the Moon 2 and require development 
of architecture in the mission formulation stage. Existing resources and legacy systems, such as International Space 
Station (ISS) and the existing space and ground network assets, will be integrated with new systems developed and 
deployed at different exploration phases; yet they will work as an integrated system of systems for supporting future 
space exploration missions. Communication systems that must interoperate include mission control centers, ground 
terminals, the Orion and Ares vehicles, Earth relay satellites, lunar relay satellites 3 , lunar surface communication 
infrastructures, Mars relay satellites, and etc. Yet all of the existing and future assets have to interoperate to realize 
the flexibility in operations enabled by the high performance SoS attributes that provide the superior 
communication, navigation, timing, and information services. These capabilities, driven by emerging exploration 
requirements, will enable future astronauts to conduct space exploration, communicate with Earth-based scientists, 
and excite future generations of explorers with high definition video and in-presence exploration, and return safely 
to earth at the end of the mission. 

The process for describing the needed communications, navigation, and networking architecture for the Orion- 
ISS Mission is being accomplished by using standard system engineering methods for defining and gathering 
capability requirements, and identifying a generalized initial architecture. Additional steps include decomposing the 
architecture and using the Department of Defense Architecture Framework (DoDAF) operational, system, and 
technical view diagramming and data capturing techniques to describe and refine the architecture as actual 
operational and functional requirements are identified. The paper describes the integrated architecture to date. 

II. Requirements of the Orion-ISS Mission 

The primary Orion-ISS mission requirement is to replace the Space Shuttle, provide delivery of cargo and crew 
to the ISS and provide both nominal and emergency return of the crew to Earth. The Orion is designed for the 
Orion-ISS mission and the Lunar Mission. Some of the high-level communication requirements of the Orion-ISS 
Mission and the extended requirements to support the Orion-Lunar Mission are: interoperability requirements for 
Command, Control, Communication, and Information (C3I), international interoperability capability, common set of 
standards, compatibility with the Tracking and Data Relay Satellite (TDRS) System (TDRSS) of the Space Network 
(SN) for RF communication links, and standardization on IP at the network layer (layered communications is 
described in section 4.C.below). The Orion-ISS Mission is required to use technology that is compatible with and 
can be extended to support the Lunar Mission. The requirements provide commonality for the physical layer 
interfaces while providing flexibility at the network layer and utilizes proven technologies. International access to 
the networks for robotic missions is achieved by adhering to the Consultative Committee for Space Data Systems 
(CCSDS) Advanced Orbiting Systems communication protocols. Interoperability requirements are essential for the 
Lunar Missions and the CEV-ISS missions will provide experience with this capability. The C3I is based on the use 
of open, standards-based interfaces, and the use of the layered models to provide sets of services. 

The Orion-ISS Mission requirements flow down to the supporting Space Communications and Navigation 
requirements at the service level. SCaN’s networks (SN, GN, and DSN) provide customer interfaces at service 
levels. Some of these service levels are low and high rate forward and return transfer services, Radiometric 
Measurement Service, and Service Management. The service level interface provides similar benefits that the 
layered model provides for communications. The service level model provides packaged choices and scheduling 
flexibility. 
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The Orion-ISS Mission requirements provide integration guidelines for SCaN’s networks and services. Currently 
DSN, SN, and GN share some resources, have similar service models, but operate independently. The Orion Lunar 
Mission will require the use of all three networks and possibly the addition of new antennas to support lunar 
communications. There will be handovers from one network to the other as Orion transitions from Low Earth Orbit 
(LEO) operations and rendezvous with LSAM to trans-lunar space. The reverse transition will occur for Orion’s 
return to Earth. This may require SN compatible RF communication links for DSN and new antennas systems 
supporting lunar communications. The Orion-ISS Mission will be supported by the SN network. The SN network is 
currently used to support the Shuttle and ISS and has experience in the unique requirements of supporting Human 
rated missions with appropriate levels of redundancy for safety. Plans are underway to add additional TDRS 
satellites compatible with the second-generation TDRS satellites. 

The Orion-ISS mission requires additional resources for launch coverage and Low Earth Orbit. The Shuttle is 
approaching 30 years of operation; however, the Orion and the Ares launch stages are new vehicles with no history. 
These vehicles will require significant amount of Development Flight Information (DFI) for launch, performance 
monitoring, first stage separation, and upper stage separation coverage during the initial flights. Additional DFI, 
mission engineering and mission operational links are required to support the real time transfer to mission systems 
and mobile ground stations during launch and ascent. There is only one Shuttle flown at a time for Shuttle-ISS 
missions. There are requirements for simultaneous coverage of multiple Orions in LEO operations. The 
simultaneous coverage requirement increases scheduling and allocation of TDRS communication resources to 
accommodate multiple Orions and other SCaN LEO customers. 

III. NASA Mission Systems and Communication Networks Interfaces 

The systems, organizations, and networks involved in Orion-ISS missions are shown in the following table. 


Primary features of the SCaN Network 

The Space Network 6 

A geo-stationary Earth orbiting (GEO) constellation of Tracking and Data Relay 
Satellites (TDRS) and ground- segments located at the White Sand Complex in Las 
Cruces, New Mexico and Guam comprise the TDRS System (TDRSS), also referred to 
as the Space Network. 

The NASA Ground Network 7 

Fixed and mobile assets located in the vicinity of the Kennedy Space Center (KSC) 
and possibly at downrange locations covering the launch trajectory of Orion into the 
ISS rendezvous orbit. 

NASA Integrated Services 
Network (NISN) 8 

Performs routed data transfer among the Earth ground assets that support 
communication among the Constellation assets (Orion and Ares vehicles to Mission 
Control and Ground Systems). 

SCaN Management 

Monitors health and security of the networks and manages the networks. 

Flight Dynamics Facility 
(FDF) 9 

Provides navigational support to missions (located at Goddard Space Flight Center 
(GSFC)). 

Constellation Program owned assets involved in the Orion-ISS Mission are: 

Orion crew exploration vehicle 

Crew module (CM), service module (SM), launch abort system (LAS), and spacecraft 
adapter (SA) 

The Ares I crew launch vehicle 
(CLV) 

The solid rocket booster (SRB) or First Stage (FS), Forward Frustum, Interstage, 
Upper Stage (US), Forward Skirt, and Instrument Unit 

The Mission System (MS) 

Includes the mission control center (MCC) 

The Ground System (GS) 

Comprised of assets at KSC used primarily for supporting launch and coordinating 
search and rescue during recovery following return to Earth of the CM. 

NASA and Other assets 

ISS, Range Operations Control Center (ROCC) in the Air Force Eastern Test Range 
(ETR). 


3 

American Institute of Aeronautics and Astronautics 

112008 




Figure 1 shows an end-to-end communication architecture overview for the Orion-ISS Mission. Here a coloring 
scheme (see the key at bottom of the figure) is used to demarcate the ownership of the assets called out in the figure. 
The Constellation Program Systems will be connecting and/or disconnecting with the SCaN networks for 
communication and tracking. The SCaN networks provides interfaces with the Constellation Program, the CxP 
space vehicles Orion and Ares I, the ISS, and ground segments MS and GS during all the mission phases. The SCaN 
network interface to the Air Force Eastern Test Range (AF ETR) is shown via the CxP GS in the figure. 


Rendezvous & Dock Return to Earth 



Prelaunch & 
Early Launch 


US Gov. 


SCaN Customers 


SCaN 


Figure 1. Overview of the Concept of Operations for the CEV-ISS mission represented using the OV-1. 


IV. SCaN Concept of Operations 


A. Pre-Launch 

During pre-launch operations at the pad (Fig. 2) there are seven primary RF communications links of interest. 


4 

American Institute of Aeronautics and Astronautics 

112008 












Ares I DFIMEL 
Test Data 


Dissimilar Voice. 
S-Band 


Ares I DFI 
Test Data 


FTS to US 
FTStoFS 




2 Radar C-Band 
Transponders in 
the Ares I : 

1 1n US 
1 1n FS 


AFROCC 


FT3(UHFj 



Communication Links 

Red 

Customer Links 

Blue 

SCaN Network 

Dashed 

— SCAN Contingency 

Green 

NISN Links 

Purple 

US Gov. (AF] Links 


Communication Nodes 

SCaN Nodes 

B 

Customer Nodes 

■ 

US Gov. (AF) Nodes 

■ 

NISN Networks 



MOL Link 


SCaN RF 
Links 


Figure 2. Pre-Launch. 

The first link is the Mission Operations Link (MOL) between Orion and MS/GS. SCaN provides the forward and 
return data transfer services between these two Constellation systems via the Space Network. These services are 
provided at S-band and are expected to transfer low rate Mission Operations data. This TDRSS connection is 
expected to be made approximately 2 hours before launch. Pre-launch checkout activities prior to T-2 hrs are not 
included in this paper. 

The second link is between Ares I and MS/GS. Low rate Mission Engineering Link (MEL) data is provided by 
SCaN via return data transfer service using the Space Network. This service is also to be provided at S-band. This 
TDRSS connection is not expected to be made until roughly 2 hours before launch. There is no S-band forward data 
transfer service to the Ares I. 

The third link is between Ares I and the AF Launch Head; this MEL data may consist of Development Flight 
Instrumentation (DFI) data that is taken during the first flights of the Ares I. This S-band direct-to-ground link 
provides the opportunity to collect sensor information and motion imagery at higher data rates. The DFI data, as the 
name indicates, will only be provided during initial Constellation flights, after which the instrumentation will be 
removed. 

The fourth link provides forward and return transfer of contingency voice data. Constellation will use SCaN- 
provided S-band dissimilar voice communication services from GN sites to relay this voice data. However, the 
complete details are still to be determined. 

Other non-SCaN related communications during launch and ascent include the AF Range Safety UHF uplink for 
flight termination, as well as C-band tracking. 

A hard-line communications connection is maintained between the Orion and Ares I for transferring Ares I MEL 
data to the Orion for transfer via TDRSS Ka-Band to Earth once the Orion reaches a stable LEO orbit, or for 
recovery post- flight. 


B. Launch/Ascent 
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The launch and ascent phase of the Orion/ Ares I Stack shown in Figs. 3 and 4 continues to rely primarily on 
SCaN services provided via the SN. The low rate forward and return mission operations data services between the 
Orion and MS/GS are provided at S-band. Return data transfer service continues to be provided for the Ares I as 
well. 


For the first -6.5 minutes of the ascent, the Ares I engineering data is transmitted on the MEL to the AF Launch 
Head as shown in Fig. 3 below. After this point, these links are dropped and the Ares I MEL real-time data is 
captured via the TDRS return data transfer service link. Ares I DFI data will be captured by the GN. 
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Figure 3. Launch/Ascent (Launch from TO to ~ T+6m 30s). 
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Figure 4. LEO (Launch from ~T+6m 30s to MECO). 


C. Low Earth Orbit (LEO) 

SCaN will continue to provide communications and tracking services through the SN when the Orion is in LEO 
(Fig. 5.). Near continuous global communication services can be provided to the Orion in LEO through the TDRSS 
relay spacecraft. Upon reaching a stable orbit, the Orion deploys the high data rate (HDR) Ka-Band and S-band 
antenna system. Ka- and S-band may be operated simultaneously on this antenna, enabling HDR transfer at Ka-band 
as well as HDR operational data at S-band. 

After the Orion is given the go-ahead from MS, chase maneuvers begin, initiating the rendezvous and docking 
events with the ISS. SCaN provides continuous support of Orion (forward and return data transfer services) through 
the LEO phase and through completion of docking with ISS when the vehicle is transitioned into quiescent mode 
and these services are reduced to periodic health and status checks. In addition to the forward and return data 
transfer to the Orion, ISS communications with the SN continue as normal, at S- and Ku-band. Communication 
between Orion and ISS for rendezvous and docking are conducted at S-band. This proximity link between Orion and 
ISS is not a SCaN-provided service. 

Contingency voice service will be provided to the Orion in LEO by SCaN at S-band from GN sites as shown in 
Fig. 5. 
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Figure 5. Rendezvous and Docking with ISS. 


D. ISS Operations 

For operations at the ISS, also shown in Fig. 5, the Orion is configured to support long-duration docked 
operations, including Orion-ISS air exchange, powering down equipment to a ‘quiescent’ mode, and activation of 
‘keep-alive’ power from the ISS. When quiescent, health and status for the docked Orion may be down linked in the 
ISS stream. State of health, control, and monitoring of Orion by ISS in the quiescent mode will be conducted via the 
ISS Common Communications Adapter (ICC A). There may not be a capability to command the quiescent Orion 
over the ISS forward link. Approximately every week Orion will be awakened to have a scheduled forward and 
return link via TDRSS for a more complete assessment. 

Once docked at the ISS, any extra-vehicular activity (EVA) conducted will be performed from the ISS using ISS 
EVA resources. The video from the EVA astronaut to the ISS is transmitted via RF S-band link while the command 
from the ISS to the EVA astronaut is at UHF. Voice communications, EVA suit telemetry, and health are also over 
UHF to the ISS. Because ISS communications channels are being used, there is no need for additional SCaN support 
to Constellation in this scenario. 

E. Return to Earth 

The entry, descent, and splashdown phase for the nominal Orion return from the ISS begins in a loiter orbit after 
undocking, and ends at Orion splashdown in the Pacific or the time that the last SM debris is expected to impact the 
Earth, whichever is later. The SCaN network will remain configured for communications and tracking support to the 
Orion CM until the vehicle reaches the earth’s surface and the SCAN is released from Mission support by 
Constellation. This support includes forward, return, and radiometric data transfer via the SN. These services will 
transfer low rate operational data provided at S-band as indicated in Fig. 6. A loss of service is expected during 
blackout. 
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The Orion must be able to return the crew to Earth without the ability to communicate with the ground during all 
activities, thus all MS functions during the entry, descent and landing phase that are required for safety must have 
some onboard backup functionality. Onboard navigation will initially be the backup system until qualified as 
primary. MS will continuously perform independent navigation and trajectory monitoring via SCaN (SN) S-Band 
tracking. 

A non-SCaN UHF link from Orion to local recovery forces is initiated at parachute deployment and will 
continue to provide connectivity between crew and recovery teams throughout final landing and recovery 
operations. The coordination of the Constellation’s GS recovery force UHF communications with the Orion is a 
Constellation responsibility. 

Contingency voice services during the reentry phase will be provided in the S-band by the SCaN GN. 
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Figure 6. Return to Earth. 


F. Recovery 

The recovery phase encompasses safmg the vehicle, powering down the vehicle, egress of the crew, safmg the 
vehicle for transportation, removal of time critical items and artifacts, and transfer of the vehicle to the 
transportation system. The following description of search and rescue team communications with CM are being 
studied and may change. 

The search and rescue team, a subset of the Constellation (GS) recovery team, will be capable of receiving the 
RF signal from the CM locator beacon. Direct voice communication with the crew during the recovery phase is 
provided via a Constellation UHF link to local recovery forces. Real time tracking information will be available to 
the recovery team. The full details for the communication links during this phase are still to be decided. 

The low rate S-band link forward and return data service via the Space Network will be maintained only until the 
vehicle is safed (on the order of 5 minutes). 

Contingency voice service during the recovery phase will be provided in the S-band by the SCaN Network. 
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V. Architecture Decomposition 


The architecture views convey the SCaN architecture to all the stakeholders (customers, system engineers, 
implementers, etc.) to assist them in verifying that the complex system of networks will address their concerns. The 
SCaN Network requires the integration of architectural practices across multiple disciplines. Such practices are 
based on the views of disparate stakeholders in the architecture; model-based analysis of elements of the architecture 
by subject matter experts; and collaboration among the stakeholders, the architect, and the experts during the 
evolution of the architecture (as captured by view development) to final consensus 4 . 

A hierarchical structure was used to develop and present the complex Orion-ISS mission phase SCaN Network 
architecture in an efficient manner to a variety of users with differing needs. Thus, the amount of detail presented 
increases with each successive level as shown in the architecture decomposition Fig. 7. The SCaN Network 
architecture was developed and described in terms of its operational, system, and technical attributes so that the user 
can gain insight into how it fulfills its mission objectives. The SCaN Network architecture is decomposed into 
segments and elements so that the parts of the Orion-ISS mission phase SCaN Network architecture can be related to 
its whole. The descriptions for each level are intended to show how segments and elements support the operational, 
system, and technical aspects of the architecture 5 . 
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Figure 7. Architecture Development Process and Decomposition. 


VI. Integrated End-to-End Architectures 


A. Communication 

The SCaN Network architecture for Orion-ISS missions includes the GN, SN, NISN, FDF, and the SCaN NCC, 
which are depicted in Fig. 8. The SCaN Network communication architecture will provide end-to-end 
communications with IP-compliant ground networks to the operations centers and S-band and Ka-band services to 
the Orion, as well as S-band services to the Ares I during all Orion-ISS mission phases as shown in Fig. 11. The 
SCaN network end-to-end S-band and Ka-band services will support communications, radiometric tracking, and 
Doppler measurement activities. For Orion-ISS missions, the end-to-end services will be based upon the Internet 
Protocol (IP) as requested by the exploration missions; therefore, the SCaN Network will support the end-to-end 
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transfer of IP packets between the Orion/ Ares I and ground-based mission elements like the MCC, as depicted in 
Fig. 8 below. 
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Figure 8. Communication Architecture. 


B. Navigation 

As the SCaN Network is deployed in space from Earth-based to lunar and Mars network support, a system of 
coarse and fine-grain navigation references will be integrated with the SCaN Network to enable future space 
explorers and applications to access navigation and position services. Navigation services for the early Orion-ISS 
crew exchange missions will be performed as shown in Fig. 10. 
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Figure 9. The Navigation and Timing Architecture for the LEO-Orbit Phase of the Orion-ISS Mission. 


C. Networking 

The SCaN Network consists of numerous new and legacy system elements included in the Ground Network, 
Space Network, Deep Space Network, NASA Integrated Services Network, and network elements that will be added 
as space exploration extends to the Moon and Mars. Some system elements, such as the Deep Space Network and 
Johnson Space Center (JSC), have over 20 years of legacy hardware, software, and policies. These networks are 
administered by different control center software systems and operational policies. To put together an IP compliant, 
end-to-end SCaN-managed network system, as shown in Fig. 11, with human rated real-time responsiveness 
requires stitching numerous different administrative systems and domains with different policies, priorities, and 
management systems into an integrated system that can plan, allocate, control, deploy, coordinate and monitor the 
resources of the network to support space exploration. Many of the legacy systems that support existing space 
missions also have to evolve into the future architecture to meet the space exploration mission requirements. 
Currently, GN, SN and DSN do not provide a network interface to missions; so it is necessary to extend network 
layer capabilities to space. The different interconnected domains pose challenges in mapping and preservation of 
Quality of Service (QoS) integrity over those multiple domains. With human lives at stake on Mars or the Moon, 
autonomous operations, autonomous error recovery, and local distributed control will have to be pervasive in the 
architecture. By the time initial Orion-ISS missions begin, SCaN will not yet provide a network layer service. CxP 
will co-locate a router between NISN’s demarcation at a SCaN ground station and the SCaN data link service. 
SCaN will use the CCSDS ENCAPS service to encapsulate IP packet data into AOS data link frames, but will not 
examine or operate upon IP packets themselves. 
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Figure 10. General End-to-End IP Network Architecture. 
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Figure 11. End-to-End IP Network Architecture in Support of the Orion-ISS Missions. 


VII. Architectural Views 

The integrated architectures for Communication, Navigation & Timing and Networks provide context and scope 
of the architectures. The architectural views provide representations of the overall architecture that are meaningful to 
one or more stakeholders in the system. The Department of Defense Architectural Framework (DoDAF) was used to 
develop operational, system and technical views as presented below. DoDAF applied to the NASA Orion Mission is 
detailed in Reference 5. 

A. Operational Views 

OV-1, the Operational Concept Views for the Orion-ISS mission were described previously and shown in Figs. 
2, 3, 4, 5 and 6 above. 
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The OV-2 or information exchange between operational nodes is shown in Fig. 12. The operational nodes are 
shown connected by unidirectional “needlines”. Furthermore the types of information exchanged are annotated on 
each needline. Fig. 12 represents a high level OV-2 representing all the phases of the mission. 



SCaN Network. Elements 
SCaN Neiwork Users 
External 


Figure 12. OV-2, Operational Information Exchange Diagram for the Orion-ISS Mission. 


B. System Views 

The System Views are of greater interest to the builders and implementers and must show how the 
communications, navigation and timing operations in the OV’s are accomplished. Some of the differences between 
SV’s and OV’s are that while OV’s show information exchange needs, SV’s show data pathways and interfaces 
exactly the way they are supposed to occur to facilitate the information exchange called out in the OV’s. The SV-1 
in Fig. 13 depicts the system nodes and interfaces between them. The level of detail represented can vary from 
showing inter-nodal interfaces to intra-nodal interfaces. In SV-1 we also introduce unique names and numbers for 
system nodes and interfaces. 

Many DoDAF diagrams and tables are not shown due to their extensive number and descriptive text. In SV-2 the 
communication description is added to the interfaces, in other words frequency bands and other data transfer 
attributes are introduced. The SV-3 is a system- to- system connectivity matrix. SV-4’s represent functional 
hierarchies and flows. The SV-4’s must be consistent with the activity hierarchy and flow diagrams established in 
OV-5. In fact the OV-5 and SV-4 diagram development is an iterative process culminating in SV-5 where a matrix 
mapping the activities to functions is the product. SV-6 is a detailed communication interface description where 
attributes and performance characteristics of communication links can be tabulated. Finally the SV-8 serves as a 
roadmap for needed upgrades or technologies. 
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Figure 13. SV-1 -- System/Service Interface Description for the Launch and Ascent Phase of the Orion- 
ISS Mission. 

The SV-1 can also be further decomposed to describe interfaces between sub-systems that reside within each 
system node. Figure 1 1 shows an example of a more detailed SV that describes the interfaces between networking 
layers for communications while Orion is in LEO. This diagram shows smaller blocks utilizing color code to 
represent the OSI layers (see Fig. 11) within which the hardware resides and operates. In order to preserve clarity 
only the critical nodes in the communication chain are shown, although the other nodes represented are also still 
present. 

C. Technical views 
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Note: The Technical View, TV-1, assoicated the standards that are going to be used in the specific system or services. In 
this case the specifications are documented in other existing documents or in an internet or accepted specification based 
on the architecture. The protocol or process establishes how the service is going to be preformed in the architecture. 


VIII. Conclusion 

An overview of the integrated communication and network architecture for the NASA Constellation Program’s 
Orion-ISS Mission has been described. The architecture addresses the role and interfaces of NASA’s Space 
Communication and Navigation Program as the provider of communication and tracking services during the various 
mission phases. The architecture description afforded by combining NASA system engineering practices and 
DoDAF formalism is new and adds a new dimension to the architecting of complex system-of-systems and the 
needed communication and network infrastructure. 
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